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REMARKS 

Claims 2-12 and 14-24 stand rejected under 35 U.S.C. §112, second paragraph as 
being indefinite. Claims 1, 2, 14, 14, and 25 stand rejected under 35 U.S.C. § 102(b) as 
being anticipated by Bezos, et al., (USP 6,029,141, filed June 26, 1997). Claims 3-10 and 
15-22 stand rejected under 35 U.S.C. §103(a) as being anticipated by Bezos in view of 
Hartman, (USP 5,960,411, filed Sep. 12, 1997). Claims 11, 12, 23, and 24 stand rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Bezos in view of Hartman, and in 
further view of Official Notice. Priority to co-pending applications has been denied 
because the pending claims lack proper support in the earlier filed application. 

Applicants thank the Examiner for the courtesy of an in-person interview of Aug. 
17 th , 2005, in which certain claim limitations were discussed along with their 
corresponding support in the specification. In particular, the transaction ID was 
discussed and its corresponding functionality as claimed in the independent claims of 
the instant application. Mr. Wesinger and the undersigned submitted that the 
functionality of the transaction ID is supported throughout the specification, and in 
particular with regards to FIG. 3, item 317, where the transaction ID is shown being 
associated with a credit card number. However, the Examiner disagreed an no 
agreement was reached in the Interview. 

The following Remarks will focus on the denial of the priority claim due to an 
alleged lack of support for the pending independent claims. The Remarks will first 
address the requirements expressed in the MPEP for making a prima facie case 
regarding a rejection due to an improper written description. The support for the 
transaction ID as claimed will then be identified in the specification. 
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The Examiner has failed to make a prima facie case for asserting a lack of support for 

the pending claims 

Regarding claims asserting the benefit of an earliest filing date, the "examiner has 
the initial burden of presenting evidence or reasoning to explain why persons skilled in 
the art would not recognize in the original disclosure a description of the invention 
defined by the claims". MPEP 2163 at 2100-183. Indeed, the Office action should 
"clearly communicate the findings, conclusions, and reasons which support them". Id. 
at 2100-184. 

The MPEP identifies a two-step process to satisfy this initial burden. First, the 
claim limitation at issue should be identified. Id. 
Secondly, the Examiner should: 

Establish a prima facie case by providing reasons why a person skilled in 
the art at the time the application was filed would not have recognized that the 
inventor was in possession of the invention as claimed in view of the disclosure 
of the application as filed. Id. 

The Examiner must have a reasonable basis to challenge the adequacy of the 
written description, and the description as filed is "adequate, unless or until sufficient 
evidence or reasoning to the contrary has been presented by the examiner to rebut the 
presumption". MPEP 2163.04. The initial burden of presenting evidence regarding the 
written description requires the Examiner to establish by a "preponderance of evidence 
why a person skilled in the art would not recognize in an applicant's disclosure a 
description of the invention defined by the claims". Id. 

Thus, the MPEP requires that in a proper statement of rejection, the Examiner 
must set forth "express findings of fact which support the lack of written description 
conclusion". MPEP 2163.05 I. These findings should: 
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(A) Identify the claim limitation at issue; and 

(B) Establish a prima facie case by providing reasons why a person skilled 
in the art at the time the application was filed would not have recognized that the 
inventor was in possession of the invention as claimed in view of the disclosure 
of the application as filed. Id. 

Applicants respectfully submit that the Examiner has failed to make a prima facie 
case to support a lack of written description rejection. It is respectfully submitted that 
the Examiner has neither identified a particular claim limitation that is at issue, nor has 
the Examiner provided any reasons why a person skilled in the art would not recognize 
in the specification a description of the invention as presently claimed. 

Indeed, the Examiner has failed to identify any reasoning whatsoever for the 
rejection. The entirety of the rejection regarding lack of support reads: 

Applicants' claim to priority to co-pending applications (10/703,823), 
(09/952,985), (09/110,708) and (08/572,543) is denied because the invention 
claimed in the current application lacks proper support in these earlier filed 
applications. Accordingly, the examiner will use the filing date of the current 
application (March 30, 2004) as the earliest priority date of the current invention. 
Office action mailed Aug. 1 1 , 2004 . at page 2. 

This rejection fails to identify which claim limitation or limitations are at issue. 
Furthermore, no reasoning is provided for the Examiner's basis for rejection. Indeed, the 
rejection fails to identify even what claim is at issue. 

No "express findings of fact" are presented, and no discussion is present as to 
why one skilled in the art would fail to find adequate description of the claims as filed in 
the specification of the parent applications. Accordingly, it is respectfully submitted that 
the Examiner has failed to make a prima facie case for denying the current application 
the earliest priority date claimed. Applicants respectfully traverse this rejection, and 
requests that the denial of the earliest priority claim be withdrawn and the pending 
claims be reconsidered in light of the earliest priority date claimed. 
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Applicants note that it is difficult to respond to the Examiner's rejection when all 

that has been presented is two-sentence conclusion devoid of any evidence or factual 

analysis. If the Examiner is still of the belief that the earliest priority date claimed is not 

properly supported, then Applicants respectfully request a more thorough Office action 

that includes which particular claim limitations are at issue, along with a presentation 

from the Examiner of a proper prima facie case as to why one skilled in the art would 

not find support in the specification for the invention as presently claimed. With a more 

reasoned analysis in hand, Applicants will then be in a better position to respond with 

particularity to the Examiner's concerns. 

The transaction ID as presently claimed is properly supported in the specification as filed 

As mentioned in the Examiner's Interview Summary and related in the 
Applicants' summary above, the Examiner took issue with the transaction ID element of 
the presently pending independent claims. Applicants will now show how proper 
support is found in the specification for the transaction ID as presently claimed. 

Independent claims 1, 13, and 25 of the presently pending claims recite, inter alia, 
a transaction ID being created in the process of a purchase transaction being performed 
on a web site. The transaction ID as claimed has purchase information associated 
therewith that is used to complete the transaction. 

Applicants are claiming an earliest priority date of Dec. 14, 1995, corresponding to 
the filing date of the original parent application now issued as US patent 5,778,367. To 
ensure that no new matter is being entered in the presently pending claims, the following 
discussion will cite columns and rows of the '367 patent as issued. 

Turning now to the '367 specification, a transaction ID is created when a user 
attempts to add content to the database: 
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In order to add an entry to the database, a user must login, during which 
the user chooses a password, or must have logged in during a previous visit to the 
site. When the user chooses to add a new entry to the database, a unique 
transaction ID is created for that entry, to be used throughout the life of the entry. 
(Col 9, lines 23-26) 



The user may then enter information on a form: 

Once a transaction ID has been assigned, the user is then provided with an 
entry form 317 having fields corresponding to the various fields of a database 
entry as described previously. (Col. 9, lines 40-43) 



The specification provides that during the entry process, a form is presented that 
corresponds to the fields of the entry: 



The form may have one or more checkboxes 319 to indicate the desire to 
include with the entry one or more non-textual elements, such as a graphic image, 
etc. Also, if desired, different templates may be provided governing the 
appearance of the finished page, with the user selecting a desired template. (Col. 
9, lines 43-49) 



It is contemplated that the graphics may be uploaded: 



Non-textual content may be obtained from the user in any of a number of 
different ways. For example, the user may transfer to the site a file containing the 
non-textual content using the File Transfer Protocol (FTP) with the same user ID 
and password as when the entry was added. (Col. 9, lines 50-54) 



The user may also indicate how the entry is to be indexed by supplying desired 
keywords: 



During the entry process, the user is prompted to enter keywords to 
facilitate later searching of the database and location of the entry. (Col. 9, lines 
55-58) 



Other information may be collected, such as credit card information as recited in 
the presently pending independent claims: 
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If the server site is based on a pay-for-service model, the form will also call 
for the user to enter a credit card number as the last piece of information. (Col. 9, 
line 65 -Col. 10, line 1) 



In another embodiment disclosed in the '367 specification regarding the secure 
updating of entries, the specification contemplates that the transaction ID may be used 
as a user ID for authentication purposes, in particular during the process of updating of 
an entry. 

The following excerpt in particular shows the transaction ID facilitating 
authentication of a user, and the retrieval of both the personal information and credit 
card information associated with the user. The user is then charged for the ability to 
post and update a web page. 



After an entry has been made, it may be updated at any time by one able to 
provide the transaction ID assigned to the entry and the user password, i.e., by 
the user or one acting on behalf of the user. The update option may be entered 
directly, or the entry to be updated may first be viewed as the result of a search 
and the update screen button 315 then pressed. The user is then prompted to 
supply the correct transaction ID and password (page 321), failing which the user 
will not be allowed to update the entry. 

If the transaction ID and password are correctly supplied, then the 
equivalent of a new entry form will be provided to the user will the current 
information pertaining to the entry already filled in. The user may then modify the 
entry. If a charge is made for updating the entry, preferably the credit card 
information from the earlier creation of the entry will have been stored in a highly 
secure fashion, avoiding the need to reenter the information. Both security and 
convenience are thereby enhanced. (Col. 10, lines 9-28) 



Thus, the 4 367 specification clearly provides support for the creation of a 
transaction ID, and the association of credit card information with the transaction ID as 
presently claimed in the instant application. The specification also provides proper 
support for the transaction ID being used to facilitate the completion of a credit card 
transaction. In embodiments fully disclosed in the '367 specification, the transaction ID 
is shown facilitating the retrieval and automatic population of a form with elements 
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previously provided by the user, and the initiation of a credit card charge process if 

necessary. 

Applicants respectfully submit that the above excerpts show the transaction ID 
element of the presently pending claims being more than adequately described in the 
specification of the '367 parent application as originally filed. The detailed description 
and associated figures therein provide a proper written description such that one skilled 
in the art would recognize the transaction ID is adequately supported as claimed. 

Applicants respectfully requests that the denial of the earliest priority claim be 
withdrawn and the pending claims be accorded the earliest priority date claimed in light 
of these remarks. 

The rejections based upon the Bezos and Hartman reference should be withdrawn as the 
present case is entitled to a filing date prior to the effective filing date of either reference 
Turning now to the 35 U.S.C. § 102(b) rejection using Bezos, and the 35 U.S.C 
§ 103(a) rejections using Bezos and Hartman, it is respectfully submitted that these 
rejections should be withdrawn as Applicants believe that the present case is entitled to 
the earliest priority date claimed, rendering both references unavailable under either 35 
U.S.C. § 102(b) or 35 U.S.C. § 103(a) as the effective filing date of both references is after 
the earliest priority date claimed in the instant case. 

T he Examiner has improperly taken Official Notice of facts 

Applicants note that the Examiner relied upon Official Notice to reject claims 11, 
12, 23, and 24. Per MPEP 2144.03, Applicants traverse the Examiner's assertion that the 
email functionality as recited in claims 1 1, 12, 23, and 24 is old and well known in the art. 

It is not clear from the record whether the Examiner is relying upon personal 
knowledge, or whether the Examiner is attempting to take Official Notice of the fact that 
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it is old and well-known for a web site to identify users using an email address and the 

sending of a password to a user at their email address. 

If the Examiner is attempting to take Official Notice of a fact, then the Examiner is 

required to point to evidence in the record to support such a finding. 

Ordinarily, there must be some form of evidence in the record to support an 
assertion of common knowledge. See Lee, 277 F.3d at 1344-45, 61 USPQ2d at 
1434-35 (Fed. Cir. 2002); Zurko, 258 F.3d at 1386, 59 USPQ2d at 1697 (holding 
that general conclusions concerning what is "basic knowledge" or "common 
sense" to one of ordinary skill in the art without specific factual findings and 
some concrete evidence in the record to support these findings will not support 
an obviousness rejection). MPEP 2144.03 B 

The Examiner has admitted in the Office action that the prior art does not teach 
the limitations as claimed in claims 11, 12, 23, and 24, and has only asserted a general 
conclusion regarding what is alleged to be old and well-known in the art. The Examiner 
has cited to Col. 1, line 66 to Col. 2, line 16 of Hartman as evidence for motivation; 
however, the cited section of Hartman is merely a general recitation of security concerns 
in the Background section in the context of the need for encryption and is irrelevant to 
the claims at issue. Therefore, the Examiner has failed to provide any substantial factual 
basis for taking Official Notice of these facts. 

If the Examiner is relying on personal knowledge, then Applicants respectfully 
request a statement putting forth the Examiner's specific reasoning for taking Official 
Notice. 

If the examiner is relying on personal knowledge to support the finding of 
what is known in the art, the examiner must provide an affidavit or declaration 
setting forth specific factual statements and explanation to support the finding. 
MPEP 2144.03 C 

Applicant respectfully traverses the taking of Official Notice, and respectfully 
submits that such a finding is inconsistent with MPEP 2144.03. 
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Applicants request that the rejections be withdrawn, and that this application be 

allowed. If the Examiner has any questions regarding this application, the Examiner may 

telephone the undersigned attorney at 775-848-5624. 



Respectfully submitted, 



Dated: February 9, 2006 




Timothy A. Brisson 
Reg. No.: 44,046 

Sierra Patent Group, Ltd. 
P.O. Box 6149 
Stateline, NV 89449 
(775) 586-9500 
(775) 586-9550 Fax 
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